[Previous] [Next] [Index] [Thread]

Re: some questions about SHTTP

> I am trying to implement a secure http server. After I read the recent
> SHTTP1.1 specification, I have some questions and would appreciate if
> anyone can give me some answers. (I'm new to SHTTP and not familiar with
> PKCS-7, PGP, so pardon me if I ask the wrong question)

I don't think it's really possible to create a secure HTTP server from the
current spec and expect it to work with the installed base without a lot of
testing in the early design stages.  Too much is left unsaid or was changed
in the implementations but not the spec.

> 1. Section 2.3.1 Content Privacy Domain
> "Support for PGP is deprecated". 
> For most of people outside USA, PKCS and PEM products are rarely available. 
> (Correct me if I am wrong and tell me where to get PEM products please,
> I am only aware of two: RIPEM and TISPEM, both are not exportable outside
> USA I think) However, PGP is widely used as a public
> key encryption package outside USA. Shall we still consider PGP?

Was anybody actually using it?  If not, it seems implausible that anybody
will anytime real soon.  PGP is not available inside the U.S. for commercial
use under reasonable terms, so I wouldn't expect to see anything happen with
it here.

> 2. MAC-Info (Section 2.3.5 page 8)
> in page 8, second last paragraph
> "The special key-spec 'DEK' refers to the Data Exchange Key used to encrypt
> the following message body..."
> The specification doesn't not say if key-spec is <Key-ID>, what does it
> refer to? Does it also refer to the key used to encrypt the message body?
> Is it encryption mandatory if <Key-ID> appears?(I guess so)

I believe it's the same syntax and meaning (and likely will often have the
same value) as <CoverKey-ID> from section 2.3.4 (and called <Key-ID> in
the collected syntax summary in 9.1.)

> 3. Signing Key Pattern (section 4.4.9.3, page 17)
> The syntax definition for the patern values seems has some small mistake:
> according to the example given, it seems the syntax should be like:
> <Value> := '/' <Dn-spec> (',' <Dn-spec>)* '/'
> <Dn-spec> := <Field-spec>*
> Is the example wrong or the syntax definition itself?

I think what is intended is that it be more like

<Dn-spec> := '/' <Field-spec> ( ',' <Field-spec> )* '/'

going by what the example says, but I'm not sure.

> Also according to the Your-Key-Pattern definition, the example should be:
>   Your-Key-Pattern: 'signing-key', DN-1485, ...
> The example doesn't have 'signing-key'

Looks like that's an error, yes.

> 4. Inband Key Assignment (Section 5.4.1 page 21)
> The specification says that "... However, this mechanism is also useful
> to permit key changes without public key computations"
> Q: what kind of encryption shall we use to protect the key? How do we 
> get the session key?

It is useful in cases where there exists an encrypted message (possibly
established via public-key techniques) for passing a key for use in
subsequent communications without repeating the public-key stuff every time.

> 5. Example (Section 10 page 35)
> The last message: it says "the data between the delimiters is a PKCS-7
> 'Data' representation of the request"
> Q: is the data encrypted by the inband key alice1? if not, why should
> the server use Key-Assign to send the key alice1?

I believe it is not encrypted at all under any key.  The real question is,
why wrap an unencrypted message in PKCS-7 and base64 encode it instead of
just sending it with no Content-Privacy-Domain at all?

> 6. A general question about message content
> I am quite confused about the message content (the part between
> ----BEGIN PRIVACY-ENHANCED MESSAGE---- and ----END PRIVACY-ENHANCED MESSAGE----)
> What does it mean by it is a (PKCS-7/PEM) encapsulated message? Does it
> mean it is encrypted? and what kind of encryption, which key? 

For PEM messages, the ----BEGIN--- and ---END--- lines are part of the
message format (see RFC 1421.)  Base64 encoding is also part of the message
format.  With PEM, that information (is it encrypted?  under which key?  etc.)
is part of the message body itself.

With PKCS, the ---BEGIN--- and ---END--- lines and the base64 encodings are
bad ideas that, unfortunately, can't really be gotten rid of without
obsoleting some existing implementations.
The information about whether it is encrypted and the like is also internal
to the format, except with straight encryption where the Prearranged-Key-Info
header provides it.

> Is it true that every message must be either PKCS-7/PEM encapsulated?

Unfortunately, yes.  As you point out, with messages that are not
encrypted or signed but just have a Mac-Info: header, this is kind of silly.

- Marc
Follow-Ups: References: